An 802.1BR-based network topology (referred to herein as an extended bridge) is a logical network entity that comprises two types of units: a controlling bridge (CB) unit and one or more port extender (PE) units. The CB serves as the controller of the extended bridge and is responsible for performing control plane functions (e.g., Layer 2 switching, Layer 3 routing, etc.) with respect to network traffic passing through the bridge. In contrast, the PEs, which connect the CB with other devices/hosts external to the extended bridge, act as non-intelligent devices and thus do not perform any local switching or routing; instead, their primary function is to provide additional data port terminations for the CB (thereby extending the port capacity of the CB). For example, each PE may be a switch/router with X number of physical data ports, which appear as virtual data ports on the CB. Upon receiving a data packet from an external device/host on an ingress data port, the PE forwards the data packet through an internal link to the CB, which processes the data packet in hardware or software to determine an appropriate egress port through which the packet should be sent out. The CB then forwards the data packet to the PE housing the determined egress port for transmission through that port towards the next hop destination.
Since the role of PEs in an extended bridge is relatively simple, the PEs can be implemented using relatively low-end network devices. For flexibility in deployment, some networking vendors have designed such low-end devices to support two different modes of operation: a switch/router mode and a PE mode. In switch/router mode, the network device can perform local switching and/or routing of traffic and can allow a user to configure the various rules and settings needed to support such behaviors. This allows the device to operate as a standalone switch/router in a network. In contrast, in PE mode, the network device can perform the functions of a PE unit as defined in the 802.1BR standard. As part of this mode, the network device can limit user configuration to the settings and commands that are relevant to PE mode operation.
One issue with supporting separate switch/router and PE modes as noted above is that, in existing implementations, the network device is generally required to run in a given mode in order for a user to enter and validate configuration settings for that mode. This requirement can lead to various network management problems. For example, assume that an organization has a network of high-end and low-end switches/routers in a production deployment. Further assume that the organization wishes to convert (i.e., re-deploy) the low-end switches/routers into PE units, so that traffic passing through those devices can be centrally processed at one of the high-end switches/routers (acting as a CB) for better management. In this scenario, a user must first reload each low-end switch/router from switch/router mode into PE mode, and then input and validate PE configuration settings while the device is running in PE mode. This process can be time-consuming and requires the devices to be taken offline in the production environment during PE configuration and validation, resulting in significant network downtime.
Another issue with supporting separate switch/router and PE modes is that, in existing implementations, there are generally no safeguards for preventing the network device from inadvertently switching from one mode to the other (due to, e.g., user configuration error or an unintentional device reload). Because of the significant operational differences between switch/router mode and PE mode, such an inadvertent mode switch can cause a critical failure in the network.